Troubleshooting and FAQs

Question: How does a follower License Manager maintain the information when it takes the lead in absence of primary License Manager?

When the primary License Manager goes down, it transfers all its tokens to the next follower License Manager. The new leader then maintains information as shown in the distribution table below.

For example, suppose a primary License Manager was catering to five requests and the total number of available licenses is 15. The primary License Manager just sends information about the number of license tokens issued. The new leader then maintains the information as shown below:

Scenario	Total Tokens	Issued/updated by the New Leader	Issued by the Primary Leader	Free Tokens
When the primary leader goes down	15	0	5	10
When an existing client updates its license	15	1	4	10
A new request comes up	15	2	4	9

Question: How does a client system recognize the redundant License Managers?

The client must know about at least the primary License Manager (leader License Manager). The system administrator sets each client to access the License Manager for by setting the LSHOST environment variables or allow the client to broadcast for an available License Manager. When a client requests for authorization from the leader License Manager, the leader License Manager authenticates the request and sends information about all the redundant License Managers in the pool and the licenses the pool contains.

Question: If available license count is running low and the primary License Manager is down, how can we return the commuted tokens?

If the primary License Manager is down, the commuted tokens cannot be checked in.

For example:

Suppose there are five redundant License Managers (S1, S2, S3, S4, S5, where S1 is the current leader) in a pool and the key lifetime of the redundant license X is 5 minutes.

>Let’s say, License Manager S1 goes down. and the next-highest priority License Manager S2 takes the lead.

>Initially, License Manager S2 waits for the first update calls from the clients. The waiting period is equivalent to the number of redundant License Managers in a pool * the key lifetime defined in the license (i.e. 5 X 5 = 25 minutes).

>If the update from the clients do not come in 25 minutes, all those tokens become free.

>If the updates are received before 25 minutes, then the License Manager S2 again waits for successive updates from the clients. The waiting period is now the lifetime period of a license, 5 minutes. If again, the updates do not reach within 5 minutes, all those tokens become available for reuse.

Question: The License Manager pool consists of many down License Managers in a row. So too much time is taken to build the client information when each down License Manager is contacted and then eliminated after the waiting period. Is there any way to speed up the retrieval of the client information?

Call the VLSgetServerNameFromHandle API function before and after the LSUpdate call to determine whether the contacted License Manager has changed or not. If the License Manager name has changed, then it indicates that the last-contacted License Manager was down and due to this LSUpdate could not reach it. In this case, the client should make the next update call immediately.